IMPROVED MOBILE INTERNET PROTOCOL DEPLOYMENT 

Thiskivention relates to the use of mobile Internet Protocol in the Universal 
Mobile Telephonbs^stem (UMTS) and the General Packet Radio System (GPRS), and 
relates in particular to^h^support of intra-PLMN (Public Land Mobile Network) user 
mobility by means of Mobilelhtonet Protocol. 

With the rapidly growing ufe€^of Internet Protocol (IP), an eflfective method of 
supporting mobility in UMTS and GPR^s^ use of protocols developed by the Internet 
Engineering Task Force(rETF) is highly desihbljle. 

At present, when a MobUe System (MS) moves within the PLMN, its mobility is 
supported by movement detection algorithms defined in RFC2002 (Request For 
Comments 2002). These algorithms entail the reception of mobile IP Foreign Agent 
^A) advertisements (i.e. messages sent by a mobile to a set of network nodes to 
indicate that the mobile is attached to that network). To save radio resources, it is not 
advisable to send such advertisements periodically to each MS. On the other hand, 
there is no shared channel available to transmit the advertisements to all the MSs, 

It is arTlJbjeqt^f the invention to provide a method arid apparatus by which 
advertisements can be sentto""aiviS-e;5ciendy, and with minimum handover latency. 

In current telecommunications networks, packet mobility is defined for GPRS in 
TS (Telecommunication Standard) GSM03.60. Internet Protocol mobility support is 
defined in RFC2002 for IETF. 



BEST AVAILABLE COPY 

AMENDED SHEET t 



06-08-2001 ^ ^ GB0001486 




A paper by C. Perkins entiUed "RFC 2002: IP Mobility Support' IETF 
RFC - Request for Comments, October 1996(1996-10), XP002123919 is referred to as 
background. 

5 It is known from a European patent application EP-A-09 1 841 7 to 

provide a method of supporting mobile Internet protocol in a packet radio system upon a 
mobile system moyiiig from a former routing area to a new routing area and sending to 
a controlling support node a routing area update message, in which on receipt of said 
routing area update message, a mobile Internet protocol agent advertisement is sent 
10 from a controlling support node only to said mobile system. 

The present invention is characterised over the disclosure of EP-A- 
09 1 841 7 in that the radio system is a General Packet Radio System (GPRS) and the or 
each controlling support node(s) is a Serving GPRS Support Node (SGSN). 

The inVe^on will be described by way of example only with reference 
15 to the accompanying drawingsuTwhich: 

Figure 1 illustrates schematically the GPRS; 

Figure 2 illustrates a deployment sceiuirio which can be implemented by 
application of the invention; 
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Figure 3 illustrates exchange of messages between various parts of the UMTS 
during an inter-Intemet GPRS support node routing area update; 

Figure 4 illustrates exchange of messages during an intra-Internet GPRS 
Support Node Routing Area update; and 

5 Figure 5 illustrates the exchange of messages during a serving radio network 

subsystem relocation. 

<r-i^JEiSure^ mobile system (MS) 12 in the GPRS 10 is connected across a 
radio interface Urn to-^io Network ControUer 14 which is connected through an 
^1 Serving GPRS Support l^^^d^^SN) 16 and a Gateway GPRS Support Node 
(GGSN) 18 to the Internet 20. Th^^.CtM2^C 14 and GSNs 16 and 18 represent a 
public Land Mobile Network, and the SGSlvhf^^jii^ be connected to a GGSN 22 of 
another PLMN 24. 

Figure 2 shows a desired scenario for mobile IP deployment in UMTS/GPRS 
A PLMN backbone 30 has two GPRS Support Nodes 32, 34 each providina a Foreion 
15 Agent (FA) 36, 38 for Internet access through MIP tunnels 40, 42. The first MIP 
tunnel 40 passes to a Home Agent (HA) 44 of the Internet 46, i.e. the tunnel gives 
direct access to the Internet. The second tunnel 42 passes to an HA 48 of a private 
network or home Imernet Service Provider (ISP) 50, i.e. it gives remote network 
access. 

20 Application of the invention permits this advanced scenario of MIP deployment 

to be implemented, without changing TS GSM04.0S and TS UMTS 24.008 and with 

minimum changes in existing GPRS standards. 

TS GSM04.08 describes, among other aspects, the GPRS mobility 

management. Similarly, TS UMTS 24.008 describes the UMTS mobility management. 
25 When a MS moves from one RA to another RA, the MS performs a RA~update 

procedure as part of mobUity management. This protocol is used between the MS 12 

andthe SGSN 16. 

The session activation and initial registration are completely identical to the case 
in which the FA is placed at a GGSN (referenceTdocs2m99036). For implementation 
30 of the invention, it is assumed that every ISGN is equipped with an FA. The Internet 
GSN may be a Serving GSN which behaves in a different way when the Access Point 
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Node (?) (APN) specified in the Packet Data Protocol (PDP) context activation request 
or in the subscription data selects mobile IP mode of operation. Instead of sending a 
PDP context activation request to the GGSN, the IGSN sends a PDP context Creation 
Response to the mobile terminal and triggers a FA to send the advertisement to the 
5 mobile which is requesting the activation of a session, in the same way as is done when 
the FA is at the GGSN. 

The difference with respect to the case where the FA is at a GGSN non-co- 
located with the SGSN is in that inter-ISGN mobility is handled by mobile IP, with the 
optional support of existing SGSN specific functionality in order to transfer packets 
1 0 from one IGSN to another when handover occurs. 

In a description below in which RA update procedures are described, the 
approach is chosen to highlight the differences with respect to current specifications, in 
particular with GSM TS03.60. 

The reception at the SGSN 16 of a RA update message can be used to trigger a 
1 5 MIP agent advertisement on the traffic channels to the MS performing the RA update. 
In this way, existing MIP movement detection algorithms can be used to detea the 
change of FA. 

A change of FA may be associated with entering a new RA. A new RA may, or 
may not, be under the coverage of different FA. RAs associated to different SGSNs are 
20 necessarily associated with different FAs. RAs belonging to the same SGSN may be 
associated with different FAs, depending on the choice of the network operator. 

Referring now to Figure 3, suppose an MS 60 moves so as to change from the 
area of an old Internet GSN 62 to the area of a new Internet GSN 64. The Home 
Location Register (HLR) 66 and Home Agent 68 of the MS 60 are also involved in the 
25 messaging shown in the Figure. 



STEP 1 

The MS 60 sends a routing area update request (the old Routing Area Identity 
(RAI)) old Packet Temporary Mobile Subscriber Identity (P-TMSI) Signature, Update 
30 Type to the new SGSN 62. The Update Type indicates whether the RA update is 
periodic or not: periodic updates happen at regular intervals, the non periodic at RA 

3 
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boudary crossing) or a periodic RA update. The Base Station System (BSS) associated 
with the old SGSN 62 adds the Cell Global Identity including the Routing Area Code 
(RAC) and the Location Area Code (LAC) of the cell from which the message was 
received before passing the message to the new SGSN 64. 

• 5 

STEP 2 

The new SGSN 64 sends an SGSN Context Request (the old RAI, the 
Temporary Link Layer Identity (TLLI), the old P-TMSI Signature, the new SGSN 
Address) to the old SGSN 62 to get the Mobility Management (MM) and the Packet 

1 0 Data Protocol (PDP) contexts for the MS 60. The old SGSN 62 validates the old P- 
TMSI signature and responds with an appropriate error cause if it does not match the 
value stored in the old SGSN 62. This initiates a security function in the new SGSN 
64. If the security functions authenticate the MS 69 correctly, the new SGSN 64 will 
send an SGSN Context Request (old RAI, TLLL MS Validated, new SGSN address) 

15 message to the old SGSN 62. The MS Validated inclusion indicates that the new 
SGSN 64 has authenticated the MS 60. If the old P-TMSI signature was valid or if the 
new SGSN 64 indicates that it has authenticated the MS 60, the old SGSN 62 responds 
with SGSN Context Response (MM context, PDP contexts. Logical Link layer (LLC) 
Ack). If the MS 60 is not Icnown in the old SGSN 62, the old SGSN responds with an 

20 appropriate error cause. The old SGSN stores the new SGSN address, to allow the old 
SGSN to forward data packets to the new SGSN. LLC Ack contains the 
acknowledgements for each LLC connection used by the MS 60. Each PDP context 
ijicludes the GPRS Tunneling Protocol (GTP) sequence number for the next downlink 
Network layer Protocol Data Unit (N-PDU) to be sent to the MS 60 and the GTP 

25 sequence number for the next uplink N-PDU to be tunneled via a mobile IP tunnel to 
the HA; referring again to Figure 2, the mobile IP tunnel can be either tunnel 40 or 
tunnel 42. The old SGSN 62 starts a timer and stops the transmission of N-PDUs to 
the MS 60. 

30 STEP 3 

Security functions may be executed. These procedures are standard. Ciphering 
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mode is set if ciphering is supported 

STEP 4 

The new SGSN 64 sends an SGSN Context Acknowledgement message to the 
5 old SGSN 62. This informs the old SGSN that the new SGSN is ready to receive data 
packets belonging to the activated PDP contexts. The old SGSN 62 marks in its 
context that the Mobile Switching Centre (MSC) Visitor Location Register (VLR) 
association and the information in the HLR are involved. Tliis triggers the MSCAHLR 
and the HLR to be dated if the MS 60 initiates a routing area update procedure back to 
10 the old SGSN 62 before completing the ongoing routing area update procedure. If the 
security functions do not authenticate the MS 60 correctly, then the routing area update 
is rejected and the new SGSN 64 sends a reject indication to the old SGSN 62. The old 
SGSN 62 continues as if the SGSN context request was never received. 

15 STEP 5 

The old SGSN 62 duplicates the buffered N-PDUs and starts tunneling them to 
the new SGSN 64. Additional N-PDUs received before the timer described in step 2 
expires are also duplicated and tunneled to the new SGSN. N-PDUs that were already 
sent to the MS 60 and that are not yet acknowledged by the MS are tunneled together 
20 with the number of the LLC frame that transferred the last segment of the N-PDU. No 
N-PDUs shall be forwarded to the new SGSN after expiiy of the timer described in step 
2. 

STEP 6 

25 The new SGSN 64 informs the HLR 66 of the change of SGSN by sending 

Update Location (SGSN Number, SGSN Address, IMSI) to the HLR. 

STEP 7 

The HLR 66 sends Cancel Location (IMSI, Cancellation Type) to the old 
30 SGSN 62 with Cancellation Type set to Update Procedure. If the timer described in 
step 2 is not running, then the old SGSN removes the MM and PDP contexts. 

5 
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Otherwise, the contexts are removed only when the timer expires. This allows the old 
SGSN to complete the forwarding of N-PDUs. It also ensures that the MM and PDP 
contexts are kept in the old SGSN in case the MS 60 initiates another inter SGSN 
routing area update before completing the ongoing routing area update to the new 
5 SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI). ' 

STEP 8 

The HLR 66 sends Insert Subscriber Data (IMSI, GPRS subscription data) to 
the new SGSN 64. The new SGSN validates the MS's presence in the (new) RA. If 
10 due to regional subscription the MS is rejected, the new SGSN 64 rejects the Routing 
Area Update Request with an appropriate cause and returns an Insert Subscriber Data 
Ack (IMSI, SGSN Area Restricted Due To Regional Subscription) message to the 
HLR 66. If all checks are successful then the SGSN constructs an MM context for the 
MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 



15 



30 



STEP 9 



The HLR 66 acknowledges the Update Location by sending Update Location 
Ack (IMSI) to the new SGSN 64. 

20 STEP 10 

The new SGSN 64 validates the MS's presence in the new RA. If due to 
regional, national or international restrictions the MS is not allowed to attach in the RA 
or subscription checking fails, then the new SGSN rejects the routing area update with 
an appropriate cause. If all checks are successfiil then the new SGSN constructs MM 
25 and PDP contexts for the MS. A logical link is established between the new SGSN and 
the MS. The new SGSN responds to the MS with Routing Area Update Accept (P- 
TMSI, LLC Ack, P-TMSI Signature). LLC Ack contains the acknowledgements for 
each LLC connection used by the MS, thereby confirming all mobUe-originated N- 
PDUs successfully transferred before the start of the update procedure. 



STEP 11 
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The MS 60 acknowledges the new P-TMSI with a Routing Area Update 
Complete (P-TMSI, LLC Ack). LLC Ack contains the acknowledgements for each 
LLC connection used by the MS, thereby confirming all mobile-terminated N-PDUs 
successfully transferred before the start of the update procedure. If LLC Ack confirms 
5 reception of N-PDUs that were forwarded from the old SGSN, then these N-PDUs 
shall be discarded by the new SGSN. LLC and SNDCP in the MS are reset locaUy. 

STEP 12 

Over the newly setup link to the mobile, a Mobile IP Agent Advertisement is 
10 sent including challenge/response and NAI extensions. This is triggered in any 
convenient way and is implementation dependent. The Advertisement is sent only to 
the mobile performing the RA update (i.e. MS 60). It is sent in such a way that subnet 
prefix based movement detection algorithm which the Mobile IP spec [RFC2002] 
suggests triggers an immediate mobile IP registration (i.e. by making sure no two FA in 
1 5 the PLMN send advertisements with identical subnet prefixes). 

STEP 13 

The normal MIP registration is performed. This will be periodically repeated 
according to timers negotiated in the registration, in order to keep the MIP session 

20 alive. In the case of a rejected routing area update operation, due to Routine Area 
restrictions, the new SGSN does not construct an MM context. A reject is returned to 
the MS 60 with an appropriate cause. The MS does not re-attempt a routing area 
update to that RA. The RAI value is deleted when the MS is powered-up. If the timer 
described in step 2 expires and no Cancel Location (IMSI) was received from the HLR, 

25 then the old SGSN shall stop forwarding N-PDUs to the new SGSN. If the routing 
area update procedure fails a maximum allowable number of times, or if the SGSN 
returns a Routing Area Update Reject (Cause) message, the MS is caused to enter 
IDLE state. 

30 Figure 4 illustrates the simpler messaging which is appropriate when an Intra- 

IGSN Routing Area Update is performed. 
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STEP 1 

The MS 60 sends a Routing Area Update Request (old RAI, old P-TMSI 
Signature, Update Type) to the SGSN 62. Update Type indicates RA update. The 
5 BSS associated with SGSN 62 adds the Cell Global Identity including the RAC and 
LAC of the cell where the message was received before passing the message to the 
SGSN, see GSM08.18. 

STEP 2 

1 0 Security functions may be executed. These procedures are standard. 



STEP 



The SGSN 62 validates the MS's presence in the new RA. If due to reaional, 
national or international restrictions the MS is not allowed to attach in the RA or 
15 subscription checking fails, then the SGSN rejects the routing area update with an 
appropriate cause. If all checks are successful then the SGSN updates the MM context 
for the MS. A new P-TMSI may be allocated. A Routing Area Update Accept (P- 
TMSI, P-TMSI Signature) is returned to the MS 60. 

20 STEP 4 

If P-TMSI was reallocated, the MS acknowledges the new P-TMSI with 
Routing Area Update Complete (P-TMSI). 

STEP 5 

25 If the New routing area is under the domain of a new FA (e.g. for load sharing 

reasons) then a Mobile IP Agent Advertisement is sent including challenge/response 
and NAI extensions. This is triggered in any convenient way and is implementation 
dependent. It is sent only to the mobile performing the RA update (i.e. MS 60). It is 
sent in such a way that subnet prefix based movement detection algorithm the Mobile 

30 IP spec [RFC2002] suggests trigger an immediate mobile IP registration (i.e. by making 
sure no two FA in the PLMN send advertisements with identical subnet prefixes). 
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STEP 6 

The regular MIP registration is performed. This will be periodically repeated 
according to timers negotiated in the registration in order to keep the MIP session alive. 

5 

If the routing area update procedure fails a maximum allowable number of 
times, or if the SGSN returns a Routing Area Update Reject (Cause) message, the MS 
60 enters IDLE state. 

The lifetime of the MIP registration should be set to a value » periodic RA 
1 0 updates interval (Timer T33 12) so that the necessity to send MIP Registration does not 
arise more frequently than Periodic RA updates. 

The lifetime of a MIP advertisement should be set to a value » T3312 as well, 
so that attempts to register are not more frequent than Periodic RA updates (a short 
Advertisement lifetime may require sending many advertisements over the air, or, 
1 5 missing this, it may trigger the mobile to re-register frequently, since the lifetime based 
movement detection algorithm may be triggered). Periodic RA updates should not 
trigger MIP registrations. 

Consider now a Serving Radio Network Subsystem (SRNS) relocates the 
UMTS. When the mobile is in idle mode, the procedures defined for GPRS work the 
20 same way in UMTS. When the mobile is in connected state, the SRNS relocation 
procedure illustrated in Figure 5 takes place. When the word "SGSN" is used, it is 
used to indicate a functionality and not a physical node. 



STEP 1 

25 UTRAN (reference 14 in Figure 1) makes the decision to perform the Serving 

RNC relocation procedure. This includes decision on into which RNC (Target RNC 74) 
the Serving RNC functionality is to be relocated. The source SRNC 72 sends SRNC 
Relocation required messages to the SGSN 76. This message includes parameters such 
as target RNC identifier and an information field that is passed transparently to the 

30 target RNC. 



9 
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STEP 2 

Upon reception of SRNC Relocation required message the SGSN 76 
determines from the received information that the SRNC relocation will (in this 
example) result in change of SGSN. The SGSN will then send a Forward SRNC 
5 relocation request to the applicable SGSN, SGSN 78 including the information received 
from the Source RNC 72 and necessary information for the change of SGSN (e.g. MM 
context, PDP context). 

STEPS 

10 The SGSN 78 wiJl send a SRNC Relocation Request message to the taraet 

RNC 74. The message includes information for building up the SRNC context, 
transparently sent from Source RNC 72 (e.g. UE id., no of connected CN nodes, UE 
capability information), and directives for setting up lu user plane transport bearers. 
When the lu user plane transport bearers have been established, and target RNC 

15 completed its preparation phase, SRNC Relocation Proceeding 1 message is sent to the 
SGSN 7S. 

STEP 4 

When the traffic resources between target RNC 74 and SGSN 78 has been 
20 allocated and the SGSN7S is ready for the SRNC move, then the Forward SRNC 
Relocation Response is sent from SGSN78 to SGSN76. This message indicates that 
necessary resources have been allocated for the SRNC relocation. 

STEP 5 

25 When the Forward SRNC Relocation Response has been received in the 

SGSN76, the SGSN76 indicates the completion of preparation phase at the CN side for 
the SRNC relocation by sending the SRNC Relocation Proceeding 2 message to the 
Source RNC72. 

30 STEP 6 

When the source RNC 72 has received the SRNC Relocation Proceeding 2 

10 
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message, the source RNC sends a SRNC Relocation Commit message to the target 
RNC 74. The target RNC executes switch for all bearers at the earliest suitable time 
instance. 

5 STEP 7 

InuTiediately after a successflil switch at RNC, target RNC (=SRNC) sends 
SRNC Relocation Complete message to the SGSN 78. The SGSN will also send a 
Complete SRNC Relocation towards the SGSN 76. 

10 STEPS 

At reception of the Complete SRNC Relocation, SGSN 76 will send a release 
indication towards the Source RNC. This will imply release of all UTRAN resources 
that were related to this UE. 

1 5 Mip 1 ; Over the newly setup link to the mobile (the target RNS is now acting as 

SRNS) a Mobile IP Agent Advertisement is sent including challenge/response and NAI 
extensions. This is triggered in any convenient way and is implementation dependent. 
It is sent only to the mobile performing the SRNS relocation (i.e. MS 70). It is sent in 
such a way that subnet prefix based movement detection algorithm the Mobile IP spec 

20 [RFC2002] suggest triggers an immediate mobile IP registration (i.e. by making sure no 
two FA in the PLMN send advertisements with identical subnet prefixes). 

When the target RNC is acting as Mip 2: the normal MIP registration is 
performed. This will be periodically repeated according to timers negotiated in the 
registration, in order to keep the MIP session alive. 



25 



STEP 9 

SRNC sends New MM System Information to the UE indicating e.g. relevant 
Routing Area and Location Area. Additional RRC information may then also be sent to 
the UE, e.g. new RNTI identity. 



30 
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The SGSN 78 informs the HLR SO of the change of SGSN by sending Update 
GPRS location (IMSI, new SGSN address etc) to the HLR. The HLR cancels the 
context in the old SGSN, SGSN 76, by sending Cancel Location (IMSI). The SGSNl 
76 removes the context and acknowledges with Cancel Location Ack. The HLR 80 
5 sends Insert subscriber data (IMSI, subscription data) to the SGSN 78. The SGSN 78 
acknowledges with Insert Subscriber Data Ack. The HLR acknowledges the Update 
GPRS location by sending Update GPRS Location Ack to the SGSN 78. 

STEP 1 1 

10 At reception of Insen subscriber data from HLR 80 the SGSN 78 will initiate 

the update of MM information stored in the MS 70. This done by sending Network 
Initiated Routing Area Update Command to the MS 70. This message will include new 
RAI:, and possible also new P-TMSL When the MS70 has made necessary updates it 
answers with Network Initiated Routing Area Update Complete. 

15 

Of the three procedures described with reference to Figures 3, 4 and 5, any procedure 
can be applied to either of the MIP tunnels 40, 42 in Figure 2. 

Implementation of the invention allows efficient use of radio resources, and 
provides optimal handover performance. 
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